Security is a fundamental issue in network communications, particularly where it involves the sharing of resources over the network. In a distributed system, resources (e.g., hardware resources such as printers, data resources such as files, and software resources such as applications) located at remote computers communicate and coordinate their actions by passing messages. Examples of such distributed systems include: the Internet; an intranet (a portion of the Internet managed by an organization); and a mobile computing network.
Security may encompass a desire to guarantee the privacy, integrity and/or availability of resources in a distributed system. Cryptography provides a basis for authentication of messages, as well as their secrecy and integrity. Cryptography is implemented through a security protocol, the protocol defining the cryptographic algorithms used, and the management of keys. Public-key cryptography makes it easy to distribute cryptographic keys, but its performance may be inadequate for the encryption of bulk data. Secret-key cryptography is more suitable for bulk encryption tasks. Hybrid protocols, such as Secure Sockets Layer (SSL), establish a secure channel by public key cryptography and then use the secure channel to exchange secret keys for use in subsequent data exchanges.
Some programming languages enable programs (executable code) to be loaded into a local process from a remote server and then executed locally; the transferred code generally being referred to as “mobile code.” In such cases, the internal interfaces and objects within the local process are exposed to attack by the mobile code.
Java™ is perhaps the most widely used language of this type. The Java Virtual Machine (JVM) is designed with mobile code in view. It gives each application its own environment in which to run. Each environment has a security manager that determines which resources are available to the application. For example, the security manager might prevent an application from reading and writing files, or give it limited access to a network connection.
Java applets are a well-known and widely-used example of mobile code. A user, running a browser, selects a link to an applet whose code is stored on a web server. The code is downloaded to the browser and runs on the browser locally to provide, for example, a better interactive response—i.e., one that does not suffer from the delays and variability of bandwidth associated with network communications. FIG. 1 illustrates the use of a Web applet; in part a), a client's request results in the downloading of applet code; and in part b), the client interacts locally with the downloaded applet.
When a user runs a program (such as a browser) that downloads mobile code (e.g., a Java applet) to be run locally on its behalf, the user has no good reason to trust the code to behave in a responsible manner. In fact, there is a danger that the downloaded code will be “malicious code” that removes files or accesses private information. To protect users against untrusted code, most browsers specify that applets cannot access local files, printers, or network sockets. Some users of applications of mobile code are able to assume various levels of trust in downloaded code. In such cases, the security managers are configured to provide more access to local resources. For example, after receiving code from a designated “trusted source”, the code may be allowed greater access to local resources.
In object-oriented distributed systems, there are many types of objects to which access control must be applied, and the decisions are often application specific. A “protection domain” is generally described as a domain that specifies the resources that can be accessed by processes executing within the domain and specifies the operations permitted on each resource. A protection domain in one implementation of an object-oriented system groups together a set of classes which are granted the same set of permissions. The protection domain is associated with a class loader from which the classes are loaded, a code source indicating the location from which the classes are loaded, and a (possibly empty) set of principals representing aspects of the identity of the entity (e.g., user) which is executing the code belonging to the classes. A given protection domain is mapped by a security policy to the set of permissions granted to classes belonging to that protection domain; the permissions themselves designate privileged resources or actions that can be accessed or exercised by parties granted the permissions.
The protection of Java programs that include mobile code is based upon the protection domain concept—local code and downloaded code may be provided with different protection domains in which to execute. There can be a protection domain for each downloaded source, with access rights for different sets of local resources, depending upon the level of trust that is placed in the downloaded code.
In an ideal world, communication would always be between mutually trusting processes and secure channels would always be used. There are many reasons why this ideal is not attainable. There is overhead (cost) associated with security procedures. Access to internal networks may be controlled by firewalls (firewalls produce a local communication environment in which all external communication is intercepted). But firewalls offer no protection against attacks from inside an organization. Finally, access to services on the Internet must be unrestricted, because the goal is to offer services to a wide range of users. Thus, security issues are simply inherent in the open nature of many distributed systems.